put plugin postinstall into a central file, which can be loaded

[evgeni]

No description provided.

[evgeni]

this (after 7 years), fixes https://projects.theforeman.org/issues/7988 🎉

[ekohl]

I like the direction. Wouldn't this actually resolve https://projects.theforeman.org/issues/7988?

[ekohl]

Can we be smart? In RPMs we have:

foreman-packaging/gem2rpm/foreman_plugin.spec.erb

Lines 20 to 24 in 461c8df

	has_assets = spec.files.any? { |f| f.start_with?('app/assets/') }
	has_apidoc = spec.files.any? { |f| f =~ %r{\Aapp/controllers/?.*/(api|concerns)/} }
	has_cronjob = spec.files.any? { |f| f =~ %r{\Aextra/.*\.cron\z} }
	has_webpack = spec.files.any? { |f| f.start_with?('webpack/') }
	has_package_json = spec.files.any? { |f| f == 'package.json' }

Should we look for files in $PLUGIN_ROOT and determine the values dynamically if the parameter wasn't passed?

[evgeni]

I guess we don't need the parameter at all in that case ;)

[evgeni]

So, something like this:

  # The output sometimes contain additional data like the following line:
  #    Found no changes, using resolution from the lockfile
  # But we really just want the path, so lets grep
  PLUGIN_ROOT="$(${BUNDLE} show ${PLUGIN} | grep '/usr/share/foreman')"
  # Make sure we got a path
  if [ -n "${PLUGIN_ROOT}" ]; then
    if [ -d "${PLUGIN_ROOT}/webpack" ]; then
      mkdir -p $PLUGIN_ROOT/public
      ln -snf /var/lib/foreman/public/webpack/ $PLUGIN_ROOT/public/webpack
    fi
  fi

[evgeni]

Even tho, looking at the actual plugins, those are all plugins that also have a package.json

[evgeni]

And calling apipie:cache:index doesn't technically hurt for plugins without API, just takes a bit of time.

[evgeni]

And because I am already talking to myself: I don't think creating this symlink for plugins that don't have package.json/webpack will actually hurt.

[ekohl]

I guess we don't need the parameter at all in that case ;)

I thought it could be useful to override. It's better to have that ability now than to need it at some point and having to go through the dance with updating Foreman and then the plugin.

Even tho, looking at the actual plugins, those are all plugins that also have a package.json

Yes. The only odd one used to be somewhere in Katello where there was a package.json but didn't use webpack. For Debian I think we can ignore that edge case.

[evgeni]

Do you absolutely want the "smart" part?

The current layout works and I don't have the time to play around with the smartness for RC1. :(

[ekohl]

I'm OK with postponing smartness. Can we open an issue for that to it doesn't get lost?

[evgeni]

I have added it to https://projects.theforeman.org/issues/7988, as it's still "in progress"

[evgeni]

To truly solve https://projects.theforeman.org/issues/7988 this needs to be used by all plugins, and then we'd need to drop the duplication in the core packages too ;)

[ehelms]

I am good with giving this a go, I think we should do so now or wait till RC1 is out given we are aiming to branch next week Tuesday.

[evgeni]

I prefer now, as otherwise it means if someone tries a test-upgrade to RC1, they might end up in an error (recoverable, but still).

[ekohl]

I'd also prefer this sooner rather than later. My biggest concern here is that we end up building ruby-foreman-puppet before foreman. Would that still work?

[evgeni]

@ekohl this is a install-time thing (postinst is just a shell script that runs when dpkg installs the package), so build order doesn't matter.