Opened 4 months ago

Last modified 2 months ago

#57698 new defect

Travis: Use the normal MacPorts installer

Reported by: ryandesign (Ryan Schmidt) Owned by: admin@…
Priority: Normal Milestone:
Component: server/hosting Version:
Keywords: Cc: l2dy (Zero King)
Port:

Description

For Travis, we currently use a custom MacPorts installer built specifically for Travis. This is an additional asset that needs to be produced every time we release a new version of MacPorts. (And it's not currently documented in the release process how to do that.) It would be great if we could eliminate that requirement and have Travis use the normal MacPorts installer.

From .travis.yml, it looks like the differences between the regular MacPorts installer and the build for Travis are:

  • The Travis build is packaged as a .tar.bz2 instead of a .pkg

From my point of view, there is no need for this difference. It's no problem to install a .pkg from the command line using the installer command.

  • The Travis build modifies the postflight script so that it does not run selfupdate

It's a little more work, but the postflight script could be extracted from the pkg, modified, and put back into the pkg before installing the pkg. Better yet, maybe we can find a way (argument? environment variable? config file? subpackage?) to let the user running installer specify whether selfupdate should be run; this would benefit not only our Travis configuration but anybody else needing similar functionality.

  • The Travis build copies the postflight script into /opt/local; after extracting the tarball, bootstrap.sh runs it and deletes it

This would be unnecessary if it were a pkg since it would run automatically.

  • The Travis build copies the .tcl files into /opt/local

I don't know why it does that. If there is a reason, perhaps it can be addressed another way.

If the problem is that Travis doesn't know what version of the MacPorts installer to download, it could determine the current version by querying macports-base/config/RELEASE_URL.

Change History (11)

comment:1 Changed 4 months ago by ryandesign (Ryan Schmidt)

In fact, Travis is currently using MacPorts 2.5.2, instead of the current version 2.5.4, because of this. That's not good.

comment:2 Changed 4 months ago by l2dy (Zero King)

It is documented in the release process.

comment:3 in reply to:  description ; Changed 2 months ago by l2dy (Zero King)

Replying to ryandesign:

From my point of view, there is no need for this difference. It's no problem to install a .pkg from the command line using the installer command.

It was done to skip the selfupdate in the postflight script, which would download and extract base and ports into /opt/local/var/macports/sources. https://github.com/macports/macports-base/blob/15c064eb508ce0c9bb82c8cfb216cd36ad1895d8/.travis.yml#L17

- sed -i "" "s/-v selfupdate/version/" portmgr/dmg/postflight
- sudo install portmgr/dmg/postflight /opt/local/

comment:4 in reply to:  2 ; Changed 2 months ago by ryandesign (Ryan Schmidt)

Replying to l2dy:

It is documented in the release process.

Oops, I didn't see that there, and I didn't realize that just doing that would automatically build and upload the new version to a place Travis could use it. Still, if that step weren't necessary, it would be simpler.

comment:5 in reply to:  3 ; Changed 2 months ago by ryandesign (Ryan Schmidt)

Replying to l2dy:

Replying to ryandesign:

From my point of view, there is no need for this difference. It's no problem to install a .pkg from the command line using the installer command.

It was done to skip the selfupdate in the postflight script

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

comment:6 in reply to:  4 ; Changed 2 months ago by l2dy (Zero King)

Replying to ryandesign:

Oops, I didn't see that there, and I didn't realize that just doing that would automatically build and upload the new version to a place Travis could use it. Still, if that step weren't necessary, it would be simpler.

We can merge the Travis configurations (in a new commit, not git-merge), but I'd suggest creating a new bintray account for uploading (currently using l2dybot). Travis CI supports deploying tags only: https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on.

comment:7 in reply to:  5 ; Changed 2 months ago by l2dy (Zero King)

Replying to ryandesign:

Replying to l2dy:

Replying to ryandesign:

From my point of view, there is no need for this difference. It's no problem to install a .pkg from the command line using the installer command.

It was done to skip the selfupdate in the postflight script

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

Sure. That's the only reason preventing us from using the pkg installers.

comment:8 in reply to:  6 ; Changed 2 months ago by ryandesign (Ryan Schmidt)

Replying to l2dy:

We can merge the Travis configurations (in a new commit, not git-merge), but I'd suggest creating a new bintray account for uploading (currently using l2dybot). Travis CI supports deploying tags only: https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on.

I don't understand the issues you're talking about, but we do have a "macports" account at Bintray that's not currently being used for anything.

comment:9 in reply to:  7 Changed 2 months ago by l2dy (Zero King)

Replying to l2dy:

Replying to ryandesign:

Replying to l2dy:

Replying to ryandesign:

From my point of view, there is no need for this difference. It's no problem to install a .pkg from the command line using the installer command.

It was done to skip the selfupdate in the postflight script

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

Sure. That's the only reason preventing us from using the pkg installers.

And of course, the bootstrap.sh script in macports-ports has to be modified to auto-discover the current version.

comment:10 in reply to:  7 Changed 2 months ago by ryandesign (Ryan Schmidt)

Replying to l2dy:

Ok, so if we had a way of preventing selfupdate when using the pkg installer, we could use that?

Sure. That's the only reason preventing us from using the pkg installers.

I'll see what I can do about adding this to the installer pkg. I have some ideas.

comment:11 in reply to:  8 Changed 2 months ago by l2dy (Zero King)

Replying to ryandesign:

Replying to l2dy:

We can merge the Travis configurations (in a new commit, not git-merge), but I'd suggest creating a new bintray account for uploading (currently using l2dybot). Travis CI supports deploying tags only: https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on.

I don't understand the issues you're talking about, but we do have a "macports" account at Bintray that's not currently being used for anything.

I'd like to use a more "official" account for uploading, e.g. macportsbot. macports on Bintray is currently an organization, not a user, and only users can have API keys to put into .travis.yml (with encryption).

Note: See TracTickets for help on using tickets.