Flex nightly Ant builds have been available on an Azure VM
(apacheflexbuild.cloudapp.net) I've been paying for over the past few
years. Microsoft has generously made some Azure credits available but it
requires a separate account and Azure VM. I've set up a new VM for Royale
builds and would like to shut down apacheflexbuild soon to save some money.
There are some choices:
1) Some other PMC member get an Azure VM and move the jobs there
2) Run Flex jobs on the new Royale VM.
For #2, we would need a volunteer or two to move the jobs. I don't have
the cycles right now and it would help to have someone else know how to do
this. The Royale VM is set up slightly differently, so there is some
thinking to do and possible some build script tweaking. Also, build
failures would come from "Apache Royale" instead of "flex.ci.builds".
> There are some choices:
> 1) Some other PMC member get an Azure VM and move the jobs there
> 2) Run Flex jobs on the new Royale VM.
There is a 3rd option and that is to run it on builds.apache.org. We did have this working at one point and I can’t see why it wouldn’t be possible to do so again.
The FlexJS builds were running on builds.apache.org  so I don’t see why the Royale builds couldn’t be there as well. What’s the requirement to run them on a seperate VM? (But that is up to the Royale PMC to decide.)
> For #2, we would need a volunteer or two to move the jobs.
Moving the Flex nightly builds to a machine where not all of the Flex PMC has access is probably not the best option IMO.
Yep we have FlexJS and Royale , but this is Maven build and we need to
have also ANT. All PMCs have access to the build server (always was like
that). Since Alex won't be paying at all for the new Azure - I personally
don't see any issue with current setup at all. We have more options for
modification of that server than in case of builds.a.o.
It is really not good if we won't move that jobs to the new Azure, cause we
loose Nightly builds of Apache Flex. :( I don't have cycles in the next
weeks to take a look either.
> > There are some choices:
> > 1) Some other PMC member get an Azure VM and move the jobs there
> > 2) Run Flex jobs on the new Royale VM.
> There is a 3rd option and that is to run it on builds.apache.org. We did
> have this working at one point and I can’t see why it wouldn’t be possible
> to do so again.
> The FlexJS builds were running on builds.apache.org  so I don’t see
> why the Royale builds couldn’t be there as well. What’s the requirement to
> run them on a seperate VM? (But that is up to the Royale PMC to decide.)
> > For #2, we would need a volunteer or two to move the jobs.
> Moving the Flex nightly builds to a machine where not all of the Flex PMC
> has access is probably not the best option IMO.
> 1.https://builds.apache.org/job/FlexJS%20Pipeline/ >
>> Yep we have FlexJS and Royale , but this is Maven build and we need
>> have also ANT.
>Jenkins can run ant builds as well.
We've used apacheflexbuilds and Erik's CI server for mustella because that
way we have control over the machine and don't have to wait for Infra to
fix things that we can fix via RDP. If you can't fix a build via Jenkins
settings you must wait on Infra, and the build you are waiting on might
have to wait on some other project's long running build. Infra has
gotten a lot better at responding in a day or two instead of a week or
two, but that's the trade-off. Also someone could become an Infra
volunteer and thus be able to fix issues as the arise. If someone wants
to move the jobs to builds.a.o and deal with working with Infra or joining
Infra and maintaining the builds as Infra requires updating versions of
things, that is a third option. But if that volunteer disappears, then
Flex is back to where it is now.
>> All PMCs have access to the build server
>Currently the Flex PMC doesn’t have access to the server AFAIK. Please
>email the login details to the Flex private list.
Justin, the Flex PMC does have access to apacheflexbuilds. And if Flex
wants to use the Royale CI server they will be given access there as well.
Stop with the FUD.
> If someone wants to move the jobs to builds.a.o and deal with working with Infra or joining
> Infra and maintaining the builds as Infra requires updating versions of
> things, that is a third option.
I would be willing to do that.
> But if that volunteer disappears, then Flex is back to where it is now.
Exactly the same could be said for someone setting up an external box and infra is likely to be around a lot longer than any external box.
> Justin, the Flex PMC does have access to apacheflexbuilds.
I never claimed they didn't, however the Flex PMC do not currently have access to the new server you have set up. I assume you will be shutting down the existing apache flex build server in the near future. Do you have a timeframe for that?
> And if Flex wants to use the Royale CI server they will be given access there as well.
Well that is good to know and look forward to that happening if the Flex PMC decides to move the builds onto this new box.
> As a temporary measure it should be easy enough to set up a build on builds.apache.org that makes the release package but doesn’t run the checkin tests.
After a few minor changes to the build scripts to get the release to compile on Linux I have it set up and running here.  This produces a convenience binary but will have a have a couple of minor difference to one made on windows or OSX. The major one being the checking tests are not run during the build process. Minor things include it’s missing support for flash integration in flex, automation of the flash flex kit as both of these are not supported on Linux and it’s missing the asdocs/documentation for the mobile themes.
If you’re setting this up yourself somewhere a few thing that may help:
- TLF needs to be copied for it build. Currently this is slow between slave machines. There may be a better way to do it.
- You need to run with an unlimited security version of java
- The setup is basically run ant -f jenkins.xml followed by ant release.notests
- A couple of environment variables need to be set like so
AIR_HOME=$WORKSPACE/air/AIR\ Integration\ Kit/
- The release.notests doesn’t do a clean but the workspace is wiped on the start of the build
It seems that BLAZEDS_HOME is no longer required to set?
So far this is just a proof of concept and I not tested the Flex SDK it produces but I can’t see why their would be any major issues with it.
Infra / builds.apache.org do also have windows machines and we can restrict the build to those, that means the minor issues above disappear, and that we should be able to get the checkin and mustella tests running.
There is also the option to sign up for Microsoft credits via the program they already have set up for Apache projects?
Is this what was meant by option 1?
On 31 December 2017 09:07:30 GMT+00:00, Piotr Zarzycki <[hidden email]> wrote:
>Infra does have windows machines. Builds of Maven Royale are running on
>Windows as I think.
>On Sun, Dec 31, 2017, 02:15 Justin Mclean <[hidden email]>
>> One other minor thing is that it’s not running rat but that should be
>> to fix.
>This email has been scanned by the Symantec Email Security.cloud
>For more information please visit http://www.symanteccloud.com >______________________________________________________________________
Sent from my phone. Please excuse my brevity.
I changed the jenkins job to only run on windows boxes (of which there are 4) and it is working so that gets rid of those minor issues.
Note that you need to specify the windows version of ant and java in the job to get it working.
It’s currently not running the checkin tests but that should be possible to set up and what I’ll take a look at next.. And I also need to test the build to confirm that it’s working correctly but the build log look good to me.